-
Notifications
You must be signed in to change notification settings - Fork 164
Prepare for release #371
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare for release #371
Conversation
0331c16
to
33f7153
Compare
let reqwest_response = client.post(url).json(&body).send().await?; | ||
|
||
Ok(reqwest_response.json().await?) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be too inflexible. Let's wait for feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say so. It's missing error handling at the HTTP level at least. See this code for how GitHub's GQL API is handled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So basically return the whole response as error in case status != 200? I haven't worked with GraphQL APIs in a long time, but if I remember correctly, APIs weren't consistent on that point. I'll check the graphql spec tomorrow to see if it says anything about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find anything HTTP-specific in the spec, but there is something on graphql.org. The status code isn't important, the response should always be a GraphQL response body. I'm still going to try to return more information, and fail in a useful way if the response body isn't a valid GraphQL response.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the reqwest::Error
might already give enough context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more maintenance burden than we can take, and it is better separation of concerns. There was no good third-party wasm web HTTP client when we developed ours, but now there is. Note: the web example compiles, but graphql-hub, the public API we used, is now down.
It is opt-out, but it's a reasonable assumption that it will be there
33f7153
to
7a20ea3
Compare
It is convenient, but not worth adding an extra dependency.
- Remove gitter badge - Removed mention of graphql-client-web - Added mention of the CLI workflow
5b7eee2
to
53121eb
Compare
@h-michael @mathstuf pinging you just so you notice this, in case you want to review (no pressure though). |
let reqwest_response = client.post(url).json(&body).send().await?; | ||
|
||
Ok(reqwest_response.json().await?) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say so. It's missing error handling at the HTTP level at least. See this code for how GitHub's GQL API is handled.
use std::io::Write; | ||
|
||
let out: Box<dyn Write> = match output { | ||
Some(path) => Box::new(::std::fs::File::create(path)?), | ||
Some(path) => Box::new(::std::fs::File::create(path).unwrap()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I like dropping decent error handling along with anyhow
, but I prefer better error types even in executables, so…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem of error handling here is mostly about displaying useful context when something fails (nothing is handled). In my experience, anyhow isn't much better at this than panics. I'd be ok reverting the anyhow drop for the CLI. For reference, this is the error type I work with most of the time: https://github.com/prisma/prisma-engines/blob/master/migration-engine/connectors/migration-connector/src/error.rs — it's evolved into its current form over time, and it's exactly the right thing for error reporting in prisma.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Working on a quick error type for graphql_client_cli
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed.
struct OperationNotFound { | ||
operation_name: String, | ||
} | ||
|
||
impl Display for OperationNotFound { | ||
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { | ||
f.write_str("Could not find an operation named ")?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not write!(f, "Could not… {} …in the query document.", self.operation_name)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely an unnecessary micro-optimization, but write!()
(format macros in generals) expands to more code than it looks like. It can add up to larger binaries and compile times. I just checked on rust-playground:
use std::fmt::Write;
fn main() {
let mut out = String::new();
write!(out, "{} {} {}", ">", "abcd", "<");
}
expands to
#![feature(prelude_import)]
#[prelude_import]
use std::prelude::rust_2018::*;
#[macro_use]
extern crate std;
use std::fmt::Write;
fn main() {
let mut out = String::new();
out.write_fmt(::core::fmt::Arguments::new_v1(&["", " ", " "],
&match (&">", &"abcd", &"<")
{
(arg0, arg1, arg2) =>
[::core::fmt::ArgumentV1::new(arg0,
::core::fmt::Display::fmt),
::core::fmt::ArgumentV1::new(arg1,
::core::fmt::Display::fmt),
::core::fmt::ArgumentV1::new(arg2,
::core::fmt::Display::fmt)],
}));
}
TODO: check why the readme is missing on crates.io edit: done |
Thanks for the review, will read tomorrow |
Co-authored-by: Ben Boeckel <mathstuf@users.noreply.github.com>
0da5448
to
52bea6a
Compare
Example error: erewhon.tom.~/src/graphql-client/graphql_client_cli λ cargo run generate oi --schema-path=ui Blocking waiting for file lock on build directory Compiling graphql_client_cli v0.9.0 (/home/tom/src/graphql-client/graphql_client_cli) Finished dev [unoptimized + debuginfo] target(s) in 4.78s Running `/home/tom/src/graphql-client/target/debug/graphql-client generate oi --schema-path=ui` Error: Error generating module code: Could not find file with path: ui Hint: file paths in the GraphQLQuery attribute are relative to the project root (location of the Cargo.toml). Example: query_path = "src/my_query.graphql". Location: graphql_client_cli/src/generate.rs:75:24
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Things seem better overall, thanks.
This is mostly about reducing the amount of moving parts (dependencies, features) so the library is less effort to maintain. Notably, it replaces the custom web client with reqwest. This is in preparation for a 0.10.0 release. The commits should be reviewable separately. We will still need to update the CHANGELOG before release.
Feedback is appreciated :)
closes #338
closes #327